Digital rights management (“DRM”) and enforcement is highly desirable in connection with digital content such as digital audio, digital video, digital text, digital data, digital multimedia, software, etc., where such digital content is to be distributed to one or more users. Digital content could be static, such as a text document, for example, or it could be streamed, such as the streamed audio/video of a live event. In a typical use of a rights-management system, a user receives a piece of digital content via a network (e.g., the Internet), or on a physical medium (e.g., on a disk). Additionally, if the user is permitted to “consume” the content (e.g., play audio or video content, view textual content, execute the software, etc.), the user also receives a license for such content. The rights-management system enforces the requirement that the user can consume the content only when such consumption is permitted by the terms of the license.
Rights management systems typically rely on cryptography in at least two contexts. First, content that needs to be protected is encrypted. Second, given that any meaningful use of encrypted content requires the decryption key, the keys must be distributed only to trusted entities, and cryptographic certificates and signatures are used to establish this trust. In the simplest rights management system, the owner of encrypted content directly verifies the trustworthiness of the consumer of that content, and, if the owner is satisfied of the consumer's trustworthiness, distributes a license containing the decryption key to that consumer. Such a system, however, does not provide rich enough capabilities to be of much commercial significance. Most content —like anything else in commerce—is distributed through a complex chain or web of relationships. For example, the content owner may actually delegate to a distributor the task of issuing licenses (and, thus, keys) for content. In this case, the decoupling of the content owner from the license distributor provides greater flexibility in terms of how content gets distributed (e.g., the content owner does not need to spend time or money distributing content and operating a licensing server). On the other hand, this decoupling also requires that the content owner (who has a proprietary interest in the content) trust the license distributor (who has the power to affect the owner's proprietary interest).
In order to provide digital rights management according to one set of DRM techniques, content is stored only in an encrypted form, and then decrypted for use according to preset policies and an electronic license which defines the specific user's rights to use the content. In this way, persistent policy enforcement and protection of such content is provided at the file level.
This may be implemented using a server component and two client-side components, a rights management client and a security processor. The security processor may also be known in some systems as a “lockbox”, “blackbox” or “secure repository.” The security processor is a trusted component comprised solely of software, or of a combination of software and hardware. The security processor is responsible for all decryption, signing and policy interpretation. Thus, the security processor is the core security component on the client. Where a public key infrastructure (PKI) system is used to encrypt content, the security processor is the secure container of the unique private key assigned to the client machine, and also secures all other secrets (ex. other keys like the content key and the user's key) that might need to be managed in the process of decrypting the content. Additionally, the security processor allows only processes with the correct security to be running.
Although these components are termed secure, while they are resistant to tampering, breaches of the security may occur. It can be seen that if a vulnerability is found in the secure processor, the security of the DRM system could potentially be subverted. This might allow an attacker to decrypt, publish or redistribute protected content without licensed permission, or to publish or distribute software which allows others to gain unlicensed use of protected content. As a result, keeping the secure processor resistant to such vulnerabilities is critical to the security of the DRM system.
Traditional PKI systems use revocation protocols to respond to subversions of security (a.k.a. security “breaks”). Revocation protocols allow previously-issued credentials (ex. licenses, certificates) or other security-related components (ex. software which validates licenses or manages content) to be invalidated. That is, trust can not be established for licensed use of the DRM system if establishing that trust requires reliance on a revoked entity.
Revocation is accomplished by publishing “revocation lists” of components of the system considered untrustworthy for a given security level, such as compromised keys “broken” software modules, or insufficiently secure execution environments. A DRM client system attempting to validate a given certificate first will consult with a revocation list to determine if the security of any component implicated in establishing trust for the certificate (e.g. the author, publisher, or other grantor or certifier of the certificate) has been compromised. If some element in the certificate chain or other component, such as software involved in validating the certificate, appears in the revocation list, the certificate can not be trusted. One problem with using this revocation system in a DRM system is that the security processor, the very element of the system which may be compromised, is also the element of the system which controls the checking of a revocation list. The security processor or some part of its machine certificate chain may also be the subject of revocation. A compromised element may not be trusted to revoke itself.
Thus, in view of the foregoing, there is a need for a system that overcomes the drawbacks of the prior art.